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(57) ABSTRACT 

Systems, methods and computer program products are pro- 
vided for testing whether Web content has been properly 
tailored by a transcoding proxy for display within various 
requesting pervasive computing devices. Simulated Hyper- 
Text Transfer Protocol (HTTP) requests are built using 
information from one or more data files. Each simulated 
request includes a Uniform Resource Locator (URL) that 
identifies a location of Web content. Each simulated request 
also includes an HTTP header containing information about 
a respective pervasive computing device. Simulated HTTP 
requests are asynchronously issued lo respective Web serv- 
ers identified in the respective HTTP requests. An HTTP 
response to each respective simulated HTTP request is 
received and includes Web content tailored for display 
within a respective pervasive computing device associated 
with the respective simulated HTTP request. Each HTTP 
respo nse i s then compared with an expected HTTP response. 
An HTTP response that does not compare favorably with an 
expected HTTP response can be saved for later analysis. 
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SYSTEMS, METHODS AND COMPUTER 
PROGRAM PRODUCTS FOR VALIDATING 
WEB CONTENT TAILORED FOR DISPLAY 
WITHIN PERVASIVE COMPUTING DEVICES 

HELD OF THE INVENTIGN 

The present invention relates generally to the display of 
Web page content and, more particularly, to tailoring Web 
content for display in client devices. 

BACKGROUND OF THE INVENTION 

The Internet is a worldwide decentralized network of 
computers having the ability to communicate with each 
other. The Internet has gained broad recognition as a viable 
medium for communicating and interacting across multiple 
networks. The World-Wide Web (Web) was created in the 
early 1990's, and is comprised of server-hosting computers 
(Web servers) connected to the Internet that have hypertext 
documents (referred to as Web pages) stored therewithin. 
Web pages are accessible by client programs (e.g., Web 
browsers) utilizing the Hypertext Transfer Protocol (HTTP) 
via a Transmission Control Protocol/Internet Protocol (TCP/ 
IP) connection between a client-hosting device and a server- 
hosting device. While HTTP and Web pages are the preva- 
lent forms for the Web, the Web itself refers to a wide range 
of protocols including Secure Hypertext Transfer Protocol 
(HTTPS), File Transfer Protocol (FTP), and Gopher, and 
Web content formats including plain text, HyperText 
Markup Language (HTML), Extensible Markup Language 
(XML), as well as image formats such as Graphics Inter- 
change Format (GIF) and Joint Photographic Experts Group 
(JPEG). 

A Web site is conventionally a collection of Web pages 
and other files related to a particular subject that includes a 
beginning file called a "home" page. A large Web site may 
reside on a number of geographically-dispersed Web serv- 
ers. The Web site of the International Business Machines 
Corporation (www.ibm.com), for example, consists of thou- 
sands of Web pages and files spread out over various Web 
servers in locations world-wide. 

An intranet is a private computer network conventionally 
contained within an enterprise and that conventionally 
includes one or more servers in communication with mul- 
tiple user computers. An intranet may be comprised of 
interlinked local area networks and may also use leased- 
lines in a wide-area network. An intranet may or may not 
include connections to the outside Internet. Intranets con- 
ventionally utilize various Internet protocols and, in general, 
often look like private versions of the Internet. An intranet 
user conventionally accesses an intranet server via a browser 
running locally on his/her computer. 

A Web (or intranet) server is a computer program 
(typically running on a computer) that serves requested Web 
pages and files. A Web client is a requesting program 
associated with a user. A browser is an exemplary Web client 
for use in requesting Web pages and files from Web servers. 
A Web server waits for a Web client, such as a browser, to 
open a connection and request a specific web page (or file). 
The Web server then sends a copy of the requested item, 
closes the connection, and waits for the next connection. 

When a browser interacts with a Web server, the two 
programs typically utilize HTTP. HTTP allows a browser to 
request a specific item, which the Web server then returns 
and the browser renders. To ensure that browsers and Web 
servers can interoperate unambiguously, HTTP defines the 
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exact format of requests (HTTP requests) sent from a 
browser to a Web server as well as the format of responses 
(HTTP responses) that the Web server returns to the browser. 
Exemplary browsers for both Internet and intranet use 

5 include Netscape Navigator<& (America Online, Inc., 22000 
AOL Way, Dulles, Va.) and Internet Explorer® (Microsoft 
Corporation, Redmond, Wash.). Browsers typically provide 
a graphical user interface for retrieving and viewing Web 
pages, applications, and other resources hosted by Internet/ 

^0 intranet servers (hereinafter collectively referred to as "Web 
servers"). 

As is known to those skilled in this art, a Web page is 
conventionally formatted via a standard page description 
language such as HTML, which typically contains text and 
■^^ can reference graphics, sound, animation, and video data. 
HTML provides for basic document formatting and allows 
a Web content provider to specify anchors or hypertext links 
(typically manifested as highlighted text) to other Web 
servers and files. When a user selects a particular hypertext 
link, a browser reads and interprets an address, called a 
Uniform Resource Locator (URL) associated with the link, 
connects the browser with a Web server at that address, and 
makes a request (e.g., an HTTP request) for the file identified 
in the link. The Web server then sends the requested file to 
the Web client which the browser interprets and displays to 
the user. 

Many new electronic devices, such as personal digital 
assistants (PDAs), hand-held computers, Internet-ready 
phones, and WebTVs, are gaining access to the Internet 
and/or to intranets as client devices. Electronic devices 
including, but not limited to, PDAs, cellular telephones, and 
computing devices utilized within appliances and 
automobiles, are often collectively referred to as "pervasive" 

25 computing devices. Many such pervasive computing devices 
utilize the Microsoft® Windows CE and 3Com Palm Com- 
puting® platforms. 

Unfortunately, the capabilities of pervasive computing 
devices to receive, process, store and display Internet con- 

40 tent may vary. For example, pervasive computing devices 
typically have displays that are small in size compared with 
desktop computer displays. As a result, content portions of 
a Web page, such as images and rendered HTML that may 
be otherwise displayable on a desktop computer display, 

45 may not be displayable on a pervasive computing device 
display unless some modifications to the images and/or text 
(i.e., the content) are made. For example, a desktop com- 
puter display having an array of 1024 pixels by 768 pixels 
may be able to display a large (e.g., 2 megabyte), 24 bit per 

50 pixel color image. A pervasive computing device with a 
display having an array of 120 pixels by 120 pixels, and with 
the ability to display only about 3 bits per pixel, may ignore 
much of the image data. As a resuh the image may not be 
displayed properly, if at all, via the pervasive computing 

55 device display unless the size of the image is transformed to 
the pervasive computing device's capabilities. Furthermore, 
some pervasive computing devices may not be capable of 
displaying certain image file types such as JPEG or GIF. 
Text fonts and sizes within Web content may also need to 

60 be changed to permit the display thereof within a pervasive 
computing device display. Furthermore, common HTML 
features such as frames and tables may not be displayable by 
pervasive computing devices. Data within frames and tables 
may need to be removed and/or reformatted into other 

65 configurations for proper display. In addition, performance 
limitations of pervasive computing devices, such as memory 
size and connection bandwidth, may also require changes to 
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Web page content for proper display thereof via a pervasive built using information from one or more data files. Each 

computing device. simulated request preferably includes a Uniform Resource 

It is known to take Web content that may not be properly Locator (URL) that identifies a location of Web content, 

displayable via a pervasive computing device and "tailor*' Each simulated request also preferably includes an HTTP is 
the Web content into a format that is displayable. For 5 header containing information about a respective pervasive 

example, large, high resolution, color images can be trans- computing device. Exemplary pervasive computing device 

formed into small, black and white images that can be information included within an HTTP header may include, 

displayed within small, low resolution displays. The tailor- *>ut is not limited to, an identification of a device's browser, 

ing of video, images, audio and text for display within a an identification of a device's operating system, character- 
client device typically is referred to as "transcoding." Web 1° islics of a device's display, and information about Web 

content transcoding is described in detail in pending U.S. content a device is configured to display, 

patent application Ser. No. 09/239,935 now U.S. Pat. No. Simulated HTTP requests are issued to respective Web 

6,535,896 and Ser. No. 09/240,137 now U.S. Pat. No. servers identified in the respective HTFP requests. An HTTP 

6,457,030 which are assigned to International Business response to each respective simulated HTTP request is 

Machines Corporation and which are incorporated herein by received and includes Web content tailored for display 

reference in their entirety. Web content transcoding is typi- within a respective pervasive computing device associated 

cally performed by a transcoding proxy associated with a with the respective simulated HTTP request. Each HTTP 

Web server. Products for transcoding Web content for dis- response is then compared with an expected HTTP response, 

play by a requesting client device are known. An exemplary An HTTP response that does not compare favorably with an 
transcoding product is "Cocoon" available firom the Apache 20 expected HTTP response can be saved for later analysis. 

Server Foundation at http:/y] ava.apache.org. Cocoon is The present invention may facilitate determining whether 

described at http:/yj ava.apache.org/cocoon/index. html which web content is properly tailored for display within virtually 

is incorporated herein by reference. any type of client device having virtually any type of 

To perform Web content transcoding, a Web server and/or configuration without requiring that the actual device be 

transcoding proxy typically needs to know something about used in the test. As a result, use of the present invention by 

a client device making an HTTP request. As is known to Web content providers may result in considerable time 

those of skill in the art, an HTTP header accompanies HTTP savings, cost savings, and higher quality program products, 
requests to a Web server. An HTTP header typically provides 

information about a requesting cUent device and browser. BRIEF DESCRIPTION OF THE DRAWINGS 

Exemplary information proWded within an HTTP ^° ^ ^hematically illustrates the paths of an HTTP 

may mclude the size of a client device display, whether a ^ corresponding HTTP respond in a client-server 

chent device display is a color display or a monochromatic • ♦ • i j* f j- »u * * -i i. 

J. , .V r.i- 1- * i • i_ J envu-onment includmg a transcodmg proxy that tailors Web 

display, an identification of the client device browser, and an ^^„t^«f „ « ^ • a 

. , *^ .i' . 1- J • . content tor display withm requesting client devices, 

identification of the client device operatmg system. - . ^ 
„ . J . . . ,35 FIG. 2 IS a flow chart illustrating operations for validating 

Pervasive computtng devices with various browsers and Web content provided in response to a client 

configurations are bemg developed and mtroduced to market ^^^j ^^^^^ invention 

at a rapid pace. Given the variety of new pervasive com- 1__ . . , , « 

puting devices, it may be difi&cult for Web content publishers FIG. 3 is a detailed flow chart illustratmg operations for 

to tailor content so as to be adequately displayable within ^ plurality of HTTP requests and 

many diO^erent devices. As a result, a need exists for quickly validating Iranscoded Web content provided in response to 

and easily verifying that Web content tailoring is being requests according to the present invention, 

performed correctly for each type of client device making an FIG- 4 is a schematic iUustration of a data processing 

HTTP request. Currently, testing whether or not Web content system for carrying out operations of the present invention, 

tailoring is being perfonned properly is done by making FIG. 5 is a schematic iUustration of a data processing 

HTTP requests with each actual client device. system in communication with a plurality of Web servers 

Unfortunately, the ability to test Web content tailoring with and transcoding proxies, wherein the data processing system 

many different client devices may be expensive and time is configured to build and send a plurality of HTTP requests 

consuming, and may be technically infeasible to analytically and to receive a corresponding plurality of respective HTTP 

validate responses. responses according to the present invention. 

SUMMARY OF THE INVENTION DETAILED DESCRIPTION OF THE 

In view of the above discussion, it is an object of the INVENTION 

present invention to provide systems, methods and computer The present invention now is described more fully here- 
program products for simulating different client devices 55 inafter with reference to the accompanying drawings, in 

running on various software platforms to ensure that Web which preferred embodiments of the invention are shown, 

page content tailoring is performed correctly. This invention may, however, be embodied in many different 

It is another object of the present invention to facilitate the forms and should not be construed as limited to the embodi- 

display of Web pages via pervasive computing devices that ments set forth herein; rather, these embodiments are pro- 
may have smaller displays and various performance limita- eo vided so that this disclosure will be thorough and complete, 

tions as compared with desktop computing devices. and will fully convey the scope of the invention to those 

These and other objects of the present invention are skiUed in the art. Like numbers refer to like elements 

provided by systems, methods and computer program prod- throughout. 

ucts for testing (i.e., validating) whether Web content has As will be appreciated by one of skill in the art, the 
been properly tailored by a transcoding proxy for display 65 present invention may be embodied as a method, data 

within various requesting pervasive computing devices. processing system, or computer program product. 

Simulated HyperText Transfer Protocol (HTTP) requests are Accordingly, the present invention may take the form of an 
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entirely hardware embodiment, an entirely software embodi- 
ment or an embodiment combining software and hardware 
aspects. Furthermore, the present invention may lake the 
form of a computer program product on a computer-usable 
storage medium having computer-usable program code 
means embodied in the medium. Any suitable computer 
readable medium may be utilized including hard disks, 
CD-ROMs, optical storage devices, or magnetic storage 
devices. 

Computer program code for carrying out operations of the 
present invention is preferably written in an object oriented 
programming language such as JAVA®, Smalltalk or C++. 
However, the computer program code for carrying out 
operations of the present invention may also be written in 
conventional procedural programming languages, such as 
the "C" programming language, or in a functional (or fourth 
generation) programming language such as Lisp, SML, or 
Forth. 

The present invention is described below with reference 
to block diagrams and/or flowchart illiistrations of methods, 
apparatus (systems) and computer program products accord- 
ing to an embodiment of the invention. It is understood that 
each block of the block diagrams and/or flowchart 
illustrations, and combinations of blocks in the block dia- 
grams and/or flowchart illustrations, can be implemented by 
computer program instructions. These computer program 
instructions may be provided to a processor of a general 
purpose computer, special purpose computer, or other pro- 
grammable data processing apparatus to produce a machine, 
such that the instructions, which execute via the processor of 
the computer or other programmable data processing 
apparatus, create means for implementing the functions 
specified in the block diagram and/or flowchart block or 
blocks. 

These computer program instructions may also be stored 
in a computer-readable memory that can direct a computer 
or other programmable data processing apparatus to function 
in a particular manner, such that the instructions stored in the 
computer-readable memory produce an article of manufac- 
ture including instruction means which implement the func- 
tion specified in the block diagram and/or flowchart block or 
blocks. 

The computer program instmctions may also be loaded 
onto a computer or other programmable data processing 
apparatus to cause a series of operational steps to be per- 
formed on the computer or other programmable apparatus to 
produce a computer implemented process such that the 
instructions which execute on the computer or other pro- 
grammable apparatus provide steps for implementing the 
functions specified in the block diagrams and/or flowchart 
block or blocks. 

Referring now to FIG. 1, the paths of an HTTP request 
and corresponding HTTP response in a client-server 
relationship, including a transcoding proxy that tailors Web 
content, arc schematically illustrated. A client device 10 
makes an HTTP request 15 for Web content from an HTTP 
(i.6., Web) server 20. The protocol for HTTP requests and 
responses are described in detail in "Hypertext Transfer 
Protocol— HTTP/1.1", Network Working Group Request 
for Comments 2068, January 1997, which is incorporated 
herein by reference in its entirety. 

In the illustrated client-server relationship, the HTTP 
request 15 passes through a transcoding proxy 30 and is 
modified by the transcoding proxy 30, as would be under- 
stood by one of skfll in the art. The modified HTTP request 
15' is processed by the HTTP server 20 and an HTTP 
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response 25 containing the requested Web content is sent to 
the client device 10 via the transcoding proxy 30. The 
transcoding proxy 30 tailors the Web content within the 
HTTP response 25 producing a "modified" HTTP response 
5 25*. The tailored Web content in the modified HTTP 
response 25' is renderable within the client device 10. It is 
understood that a transcoding proxy 30 may be implemented 
as software code residing within the HTTP server 20, as 
software code external to the HTTP server 20, such as within 
10 a firewall, or some combination thereof. 

The present invention provides methods, systems and 
computer program products for validating transcoded Web 
content provided in response to HTIT requests without 
requiring the actual client devices to make the HTTP 
15 requests. According to the present invention, multiple client 
requests can be simulated by a single computer in commu- 
nication with one or more Web servers, such as via the 
Internet, an intranet, or other communications network. 

Referring now to FIG. 2, operations for validating 
transcoded Web content according to the present invention 
are illustrated. A plurality of simulated HTTP requests are 
built (Block 100) by a computing device using various data 
files. Each simulated HTTP request includes a Uniform 
Resource Locator (URL) that identifies the location of 
specific Web content to be displayed within a requesting 
client device. Each HTTP request also includes an HTTP 
header that contains information about a requesting client 
device and that specifies what types of Web content the 
client device is prepared to handle. As is known to those of 
skiU in the art, HTTP headers communicate information that 
Web servers and browsers use to define the type of data that 
is being exchanged therebetween. 

Simultaneous HTTP requests are preferably issued asyn- 
chronously to Web servers identified in the respective HTTP 
requests (Block 110, FIG. 2). Preferably, a computing device 
for implementing the present invention implements the 
HTTP "GET' method for each of the respective HTTP 
requests. The HTTP "GET' method, which is weU under- 
stood by those skilled in the art, is described in detail in 
"Hypertext Transfer Protocol— HTTP/l.l", Network Work- 
ing Group Request for Comments 2068, January 1997. 

An HTTP response to each HTTP request is preferably 
stored (Block 120, FIG. 2), Each HTTP response includes an 
45 HTTP header and Web content that has been tailored for 
display within a client device identified as making the 
corresponding HTTP request. Each received HTTP response 
is compared with an expected HTTP response (Block 130, 
FIG. 2). HTTP responses not matching their respective 
5Q expected responses are preferably saved for later analysis. 

As illustrated in FIG. 3, multiple simulated HTTP 
requests can be built and issued simultaneously and asyn- 
chronously up to "n" iterations, where n can be virtually any 
value. Simultaneous building and issuance of multiple, 
55 simulated HTTP requests are schematically represented by 
operations 102-1 through 130-1, operations 102-2 through 
130-2, and operations 102-n through 130-n. A detailed 
description of operations 102-1 through 130-1 is provided 
below and it is understood that these operations are the same 
60 for any of the n iterations. 

For each HTTP request, a computing device implement- 
ing the present invention preferably selects a URL defining 
Web content to be fetched fi^om a data file (Block 102-1). 
Similarly, HTTP header fields are preferably selected from 
65 a data file (Block 104-1), A selected URL and selected HTTP 
header fields are then combined to build each respective 
HTTP request (Block 106-1). Each built HTTP request is 
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then issued to the Web server identified in the built HTTP altered by the one or more application programs 603fl, 6036 

request (Block 110-1). or the operating system 602, either individually or in com- 

After a response to an HTTP request is received and bination. For obtaining input from a user, the operating 

stored (Block 120-1), a decision is made whether to build system 602, the appHcation programs 603a, 6036, or a 
another HTTP request (Block 122-1). Once a decision is 5 combination thereof may utilize user input devices 60S 

made not to build another HTTP request, each returned ?^P^^^ "^'^IT/^^ may mclude a pomting device 606 

HTTP response is compared with an expected response theTf °' '"^""^ '''^ '° 

(Block 130-1). Preferably, each failed response is stored for r. r - * t^t^ - j i- 

later analysis to determine why the Web content was not Referrmg now to FIG 5, a data processing system 600 for 
properly transcoded. lo carrymg out operations of the present mvention is illustrated 

J, J . . , * , , ,t™„ , , ^ communication with a plurality of Web servers 702 and 

llie decision to buUd another HTTP request may depend transcoding proxies 704 via a communications network, 

on the Web content returned in anHlTP request. For ^^^1, as the Internet and/or an intranet 701. In the illustrated 

example, If Web content within an HTTP response contains embodiment, one or more Web servers 702 may utilize a 

miages, the presem invention may buUd respective IOTP transcoding proxy 704 that is configured to taUor Web 

requests for each image. Accordingly, the methods of the ,3 ^^^^^^^^ ^^ove. The data processing system 600 

present invention may be recursive and the iterative steps of ^3 configured as described above to simulate HTIP requests 

FIG. 3 may continue until all types of files withm a Web ^^m multiple pervasive computing devices without requir- 

page are requested. As a result the tailonng of content of an .^t^^j computing devices to make the HTTP 

entire Web site can be validated via a data processing system ^h^ ^ata processing system 600 builds and issues 

miplementing the present invention. j^TP requests, wherein each HTTP request 

Exemplary mformation about a requesting client device includes an HTTP header that contains information about a 

that is provided within HTTP header fields may include, but respective pervasive cHent device/browser configuration, 

is not Hmited to, an identification of a browser running on These HTTP requests can then be sent to designated Web 

the client device (e.g., user-agent), an identification of the servers as asynchronous, paraUel requests. 

cUent device operating system, an identification of charac- x^e data processing system 600 is configured as described 

teristics of the client device display, and an identification of above to receive, via the Internet and/or intranet 701, HTTP 

Web content the chent device is configured to display. responses to the HTTP requests and to compare the HTTP 

Exemp ary chent device display characteristics include, but responses with expected HTTP responses. Preferably, the 
are not limited to, display size and whether or not the display 3^ ^ata processing system 600 is configured to store HTTP 

IS a color display or a monochromatic display. responses and then perform HTTP response comparison 

Referrmg now to FIG. 4. a data processing system 600 for operations as a batch process. Accordingly, the present 

carrying out operations of the present invention are sche- invention provides an efficient, cost effective way of more 

matically illustrated. As seen in FIG. 4, a data processor 601 thoroughly testing Web content tailoring for multiple per- 
may have an operating system 602 resident therein with 35 vasive computing devices without requiring the actual per- 

various application programs 603 for carrying out operations vasive computing devices. 

of the present invention and that run on the operating system The foregoing is illustrative of the present invention and 

602. In particular, an HTTP Request Builder appUcation jg not to be conslmed as Umiting thereof. Although a few 

603a IS provided to carry out the HTTP request building and exemplary embodiments of this invention have been 

issuing operations set forth in Blocks 100 and 110 of HG. described, those skilled in the art will readily appreciate that 

2 and Blocks 100 through 122-1 of FIG. 3. A Response ^any modifications are possible in the exemplary embodi- 

Comparator application 6036 is provided to carry out opera- ments without materiaUy departing from the novel teachings 

tions for companng received HTTP responses with expected and advantages of this invention. Accordingly, all such 

r^ponses set forth m Block 130 of FIG. 2 and Block 130-1 modifications are intended to be included within the scope of 

of FIG. 3. {jjjg invention as defined in the claims. In the claims. 

Still referring to FIG. 4, the applications 603a, 603b are means-plus-function clause are intended to cover the struc- 

in communication with data storage 609, which may be tures described herein as performing the recited function and 

either external or internal data storage, or a combination of not only structural equivalents but also equivalent structures, 

external and internal data storage. The HTTP Request Therefore, it is to be understood that the foregoing is 
Builder application 603a is configured to read HTTP header 50 illustrative of the present invention and is not to be construed 

elements and URLs from data storage 609, and build and as limited to the specific embodiments disclosed, and that 

issue HTTP requests as set forth in Blocks 100 and 110 of modifications to the disclosed embodiments, as well as other 

FIG. 2 and Blocks 100 through 122-1 of FIG. 3. The embodiments, are intended to be included within the scope 

Response Comparator application 6036 is configured to of the appended claims. The invention is defined by the 
compare received HTTP responses with expected responses 55 following claims, with equivalents of the claims to be 

set forth in Block 130 of FIG. 2 and Block 130-1 of FIG. 3. included therein. 

In addition, data storage 609 may be utilized to store built That which is claimed is: 

HTTP requests and to store received HTTP responses and 1. Amethod of validating Web content tailored for display 

for implementing the various method steps of the present within a pervasive computing device in response to a 
invention as one or more batch processes. go simulated request from the pervasive computing device 

As would be imderstood by one of skill in the art, the generated by a data processing system that is not the 

processor 601 displays information on a display device 604. pervasive computing device, the method comprising the 

The display device 604 has a plurality of picture elements following steps: 

(collectively referred to as a screen) which may define the building a simulated HyperText Transfer Protocol 

appearance of a graphical user interface (GUI) displayed on 65 (HTTP) request of a pervasive computing device via a 

the display device 604. The contents of the screen and, separate data processing system that is not the perva- 

therefore, the appearance of a GUI, may be controlled or sive computing device, wherein the simulated HTTP 
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request includes a Uniform Resource Locator (URL) 
that identifies a location of Web content, and wherein 
the simulated HTTP request includes an HTTP header 
that contains information about the pervasive comput- 
ing device; 5 

issuing the simulated HTTP request from the data pro- 
cessing system independently of the pervasive comput- 
ing device to a Web server identified in the simulated 
HTTP request; 

receiving at the data processing system independently of 
the pervasive computing device an HTTP response 
from the Web server, wherein the H'lTP response 
includes Web content tailored for display within the 
pervasive computing device by a transcoding proxy 
adapted to tailor Web content for display within per- 
vasive computing devices; and 

comparing the received HTTP response with an expected 
response. 

2. The method according to claim 1 wherein the pervasive 
computing device information includes at least one of an 
identification of a browser running on the pervasive com- 
puting device, an identification of an operating system 
running on the pervasive computing device, an identification 

of characteristics of a display for the pervasive computing ^ 
device, and an identification of Web content the pervasive 
computing device is configured to display. 

3. The method according to claim 1 further comprising the 
step of storing the HTTP response received in response to 
the simulated HTTP request. 

4. The method according to claim 1 further wherein the 
step of comparing the received HTTP response with an 
expected HTTP response comprises the step of storing the 
received HTTP response if the received HTTP response does 
not match the expected HTTP response. 

5. The method according to claim 1 wherein the step of 
building a simulated HTTP request via the data processing 
system comprises: 

building a plurality of simulated HTTP requests from a 
respective plurality of pervasive computing devices via 40 
the data processing system, wherein each simulated 
HTTP request includes a Uniform Resource Locator 
(URL) that identifies a location of Web content, and 
wherein each simulated HTTP request includes an 
HTTP header that contains information about a respec- 45 
tive pervasive computing device; and 

storing the plurahty of simulated HTTP requests. 

6. The method according to claim 5 wherein the step of 
issuing the simulated HTTP request via the data processing 
system to a Web server identified in the simulated HTTP 50 
request comprises asynchronously issuing the plurality of 
simulated H1TP requests via the data processing system to 
Web servers identified in each respective simulated HTTP 
request. 

7. The method according to claim 5 wherein the step of 55 
building a plurality of simulated HTTP requests via the data 
processing system comprises retrieving HTTP header fields 
and URLs from respective data files. 

8. The method according to claim 5 wherein the step of 
c ompa ring the received HTTP response with an expected 60 
HTTP response comprises comparing each received HTTP 
response with an expected HTTP response for a pervasive 
computing device associated with each respective simulated 
HTTP request. 

9. A method of validating Web content tailored for display 65 
within a plurality of pervasive computing devices in 
response to simulated requests from the pervasive comput- 



ing devices generated by a data processing system that is not 
one of the pervasive computing devices, the method com- 
prising the following steps: 

building a plurality of simulated HyperText Transfer 
Protocol (HTTP) requests for one or more pervasive 
computing devices via a separate data processing sys- 
tem that is not the one or more pervasive computing 
devices, wherein each simulated HTTP request 
includes a Uniform Resource Locator (URL) that iden- 
tifies a location of Web content, and wherein each 
simulated HTTP request includes an HTTP header that 
contains information about a respective pervasive com- 
puting device; 

asynchronously issuing each simulated HTTP request 
from the data processing system independently of the 
one or more pervasive computing devices to a Web 
server identified in each respective simulated HTTP 
request; 

receiving at the data processing system independently of 
the one or more pervasive computing devices an HTTP 
response to each respective simulated HTTP request, 
wherein each HTTP response includes Web content 
tailored for display within a pervasive computing 
device identified within a respective simulated HTTP 
request; and 

comparing each received HTTP response with an 
expected HTTP response for a pervasive computing 
device specified in each respective simulated HTTP 
request. 

10. The method according to claim 9 wherein pervasive 
computing device information within each simulated HTTP 
request includes at least one of an identification of a browser 
running on a pervasive computing device, an identification 
of an operating system running on a pervasive computing 
device, an identification of characteristics of a pervasive 
computing device display, and an identification of Web 
content a pervasive computing device is configured to 
display. 

11. The method according to claim 9 further comprising 
the step of storing the HTTP responses received in response 
to the simulated HTTP requests. 

12. The method according to claim 9 wherein the step of 
comparing each received HTTP response with a respective 
e xpect ed HTTP response comprises storing the received 
HTTP response if the received HTTP response does not 
match the expected HTTP response. 

13. The method according to claim 9 wherein the step of 
building a plurality of simulated HTTP requests comprises 
reU-ieving HTTP header fields and URLs from respective 
data files. 

14. A system that validates Web content tailored for 
display within a pervasive computing device in response to 
a simulated request from the pervasive computing device 
generated by a data processing system that is not the 
pervasive computing device, comprising: 

means for building a simulated HyperText Transfer Pro- 
tocol (HTTP) request of a pervasive computing device 
independently of the pervasive computing device, 
wherein the simulated H'^TTP request includes a Uni- 
form Resource Locator (URL) that identifies a location 
of Web content, and wherein the simulated HTTP 
request includes an HTTP header that contains infor- 
mation about the pervasive computing device; 

means for issuing the simulated HTTP request from the 
data processing system independently of the pervasive 
computing devic e to a Web server identified in the 
simulated HTTP request; 
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means for receiving at the data processing system inde- 
pendently of the pervasive computing device an HTTP 
response from the Web server, wherein the HTTP 
response includes Web content tailored for display 
within the pervasive computing device by a transcoding 5 
proxy adapted to tailor Web content for display within 
pervasive computing devices; and 

means for comparing the received HTTP response with an 
expected HTTP response. 

15. The system according to claim 14 wherein the per- jq 
vasive computing device information includes at least one of 

an identification of a browser running on the pervasive 
computing device, an identification of an operating system 
running on the pervasive computing device, an identification 
of characteristics of a display for the pervasive computing ^5 
device, and an identification of Web content the pervasive 
computing device is configxired to display. 

16. The system according to claim 14 wherein the means 
for receiving an HTTP response from the Web server com- 
prises means for storing the HTTP response. 

17. The system according to claim 14 wherein the means 
for comparing the received HTTP response with an expected 
HTTP response comprises means for storing the received 
HTTP response if the received HTTP response does not 
match the expected HTTP response. ^5 

18. The system according to claim 14 wherein the means 
for building a simulated HTTP request comprises: 

means for building a plurality of simulated HTTP requests 
from a respective plurality of pervasive computing 
devices, wherein each simulated HTTP request 30 
includes a Uniform Resource Locator (URL) that iden- 
tifies a location of Web content, and wherein each 
simulated HTTP request includes an HTTP header that 
contains information about a respective pervasive com- 
puting device; and 35 

means for storing the plurality of simulated HTTP 
requests. 

19. The system according to claim 18 wherein the means 
for issuing the simulated HTTP request via the data pro- 
cessing system to a Web server identified in the simulated 40 
HTTP request comprises means for asynchronously issuing 
the plurality of simulated HTTP requests to Web servers 
identified in each respective simulated HTTP request. 

20. The system according to claim 18 wherein the means 
for building a plurality of simulated HTTP requests via the 45 
data processing system comprises means for retrieving 
HTTP header fields and URLs from respective data files. 

21. The system according to claim 18 wherein the means 
for comparing the received HTTP response with an expected 
HTTP response comprises means for comparing each 50 
received HTTP response with an expected HTTP response 
for a pervasive computing device associated with each 
respective simulated HTTP request. 

22. A system that validates Web content tailored for 
display within a plurality of pervasive computing devices in 55 
response to simulated requests from the pervasive comput- 
ing devices generated by a data processing system that is not 
one of the pervasive computing devices, comprising: 

means for building a plurality of simulated HyperText 
Transfer Protocol (HTTP) requests of one or more 60 
pervasive computing devices independently of the one 
or more pervasive computing devices, wherein each 
simulated HTTP request includes a Uniform Resource 
Locator (URL) that identifies a location of Web 
content, and wherein each simulated HTTP request 65 
includes an HTTP header that contains information 
about a respective pervasive computing device; 



means for asynchronously issuing independently of the 
one or more pervasive computing devices each simu- 
lated HTTP request from the data processing system to 
a Web server identified in each respective simulated 
HTTP request; 

means for receiving independently of the one or more 
pervasive computing devices an HTTP response to 
each respective simulated HTTP request, wherein each 
HTTP response includes Web content tailored for dis- 
play within a pervasive computing device identified 
within a respective simulated HTTP request; and 

means for comparing each received HTTP response with 
an expected HTTP response for a pervasive computing 
device specified in each respective simulated HTTP 
request. 

23. The system according to claim 22 wherein pervasive 
computing device information within each simulated HTTP 
request includes at least one of an identification of a browser 
running on a pervasive computing device, an identification 
of an operating system running on a pervasive computing 
device, an identification of characteristics of a pervasive 
computing device display, and an identification of Web 
content a pervasive computing device is configured to 
display. 

24. The system according to claim 22 wherein the means 
f or rec eiving an HTTP response to each respective simulated 
HTTP request comprises means for storing the HTTP 
responses. 

25. The system according to claim 22 wherein the means 
for comparing each received HTTP response with a respec- 
tive expected HTTP response comprises means for storing 
the received HTTP response if the received HTTP response 
does not match the expected HTTP response. 

26. The system according to claim 22 wherein the means 
for building a plurality of simulated HTTP requests com- 
prises means for retrieving HTTP header fields and URLs 
from respective data files. 

27. A computer program product for validating Web 
content tailored for display within a pervasive computing 
device in response to a simulated request from the pervasive 
computing device generated by a data processing system 
that is not the pervasive computing device, the computer 
program product comprising a computer usable storage 
medium having computer readable program code means 
embodied in the medium, the computer readable program 
code means comprising: 

computer readable program code means for building a 
simulated HyperText Transfer Protocol (HTTP) request 
of a pervasive computing device independently of the 
pervasive computing device, wherein the simulated 
HTTP request includes a Uniform Resource Locator 
(URL) that identifies a location of Web content, and 
wherein the simulated HTTP request includes an HTTP 
header that contains information about the pervasive 
computing device; 

computer readable program code means for issuing inde- 
pendently of the pervasive computing device the simu- 
lated HTTP request from the data processing system to 
a Web server identified in the simulated HTIT request; 

computer readable program code means for receiving 
independently of the pervasive computing device at the 
data processing system an HTTP response from the 
Web server, wherein the HTTP response includes Web 
content tailored for display within the pervasive com- 
puting device by a transcoding proxy adapted to tailor 
Web content for display within pervasive computing 
devices; and 
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computer readable program code means for comparing 
the received HTTP response with an expected HTTP 
response. 

28. The computer program product according to claim 27 
wherein the pervasive computing device information 
includes at least one of an identification of a browser running 
on the pervasive computing device, an identification of an 
operating system running on the pervasive computing 
device, an identification of characteristics of a display for the 
pervasive computing device, and an identification of Web 
content the pervasive computing device is configuired to 
display. 

29. The computer program product according to claim 27 
wherein the computer readable program code means for 
receiving an HTTP response from the Web server comprises 
computer readable program code means for storing the 
HTTP response. 

30. The computer program product according to claim 27 
wherein, the computer readable program code means for 
comparing the received HTTP response with an expected 
HTTP response comprises computer readable program code 
means for storing the received HTTP response if the 
received HTTP response does not match the expected HTTP 
response. 

31. The computer program product according to claim 27 
wherein the computer readable program code means for 
building a simulated HTTP request comprises: 

computer readable program code means for building a 
plurality of simulated HTTP requests from a respective 
plurality of pervasive computing devices, wherein each 
simulated HTTP request includes a Uniform Resource 
Locator (URL) that identifies a location of Web 
content, and wherein each simulated HTTP request 
includes an HTTP header that contains information 
about a respective pervasive computing device; and 

computer readable program code means for storing the 
plurality of simulated HTTP requests. 

32. The computer program product according to claim 31 
wherein the computer readable program code means for 
issuing the simulated HTTP request via the data processing 
system to a Web server identified in the simulated HTTP 
request comprises computer readable program code means 
for asynchronously issuing the plurality of simulated HTTP 
requests to Web servers identified in each respective simu- 
lated HTTP request. 

33. The computer program product according to claim 31 
wherein the computer readable program code means for 
building a plurality of simulated HTTP requests via the data 
processing system comprises computer readable program 
code means for retrieving HTTP header fields and URLs 
from respective data files. 

34. The computer program product according to claim 31 
wherein the computer readable program code means for 
comparing the received HTTP response with an expected 
HTTP response comprises computer readable program code 
means for comparing each received HTTP response with an 
expected HTTP response for a pervasive computing device 
associated with each respective simulated HTTP request. 

35. A computer program product that validates Web 
content tailored for display within a plurality of pervasive 
computing devices in response to simulated requests from 
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the pervasive computing devices generated by a data pro- 
cessing system that is not one of the pervasive computing 
devices, the computer program product comprising a com- 
puter usable storage medium having computer readable 
program code means embodied in the medium, the computer 
readable program code means comprising: 

computer readable program code means for building a 
plurality of simulated HyperText Transfer Protocol 
(HTTP) requests of one or more pervasive computing 
devices independently of the one or more pervasive 
computing devices, wherein each simulated HTTP 
request includes a Uniform Resoiu-ce Locator (URL) 
that identifies a location of Web content, and wherein 
each simulated HTTP request includes an HTTP header 
that contains information about a respective pervasive 
computing device; 
computer readable program code means for asynchro- 
nously issuing independently of the one or more per- 
vasive computing devices each simulated HTTP 
request from the data processing system to a Web 
server identified in each respective simulated HTTP 
request; 

computer readable program code means for receiving 
independently of the one or more pervasive computing 
devices an HTTP response to each respective simulated 
HTTP request, wherein each HTTP response includes 
Web content tailored for display within a pervasive 
computing device identified within a respective simu- 
lated HTTP request; and 

computer readable program code means for comparing 
each received HTTP response with an expected HTTP 
response for a pervasive computing device specified in 
each respective simulated HTTP request. 

36. The computer program product according to claim 35 
wherein pervasive computing device information within 
each simulated HTTP request includes at least one of an 
identification of a browser running on a pervasive comput- 
ing device, an identification of an operating system running 
on a pervasive computing device, an identification of char- 
acteristics of a pervasive computing device display, and an 
identification of Web content a pervasive computing device 
is configured to display. 

37. The computer program product according to claim 35 
wherein the computer readable program code means for 
receiving an HTTP response to each respective simulated 
HTTP request comprises computer readable program code 
means for storing the HTTP responses. 

38. The computer program product according to claim 35 
wherein the computer readable program code means for 
comparing each received HTTP response with a respective 
expected HTTP response comprises computer readable pro- 
gram code means for storing the received HTTP response if 
the received HITP response does not match the expected 
HTTP response. 

39. The computer program product according to claim 35 
wherein the computer readable program code means for 
building a plurality of simulated HTTP requests comprises 
computer readable program code means for retrieving HTTP 
header fields and URLs from respective data files. 
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